• "Current Handler:" heading in the main ADB Parser window (center) was changed to
reflect reality - it is now titled "Original Handler:".
• "Current Handler:" item in the main ADB Parser window (right side) was fixed so the
actual current handler ID is displayed.
• The "Data received:" item in the main ADB Parser window (left side) was fixed so
all bytes of returned data are displayed, rather than 2. Number of returned bytes is
also shown.
Changes in 5.0.6:
• Now uses Gestalt to determine CPU type rather than SysEnvirons.
• ADB Parser will no longer accidentally open windows off-screen.
• Fixed a bug where ADB Parser would occasionally get System resources instead of
Parser's.
Changes in 5.0.5:
• Fixed a bug (implementation error) that didn't allow handler IDs which were
greater than $F. ADB Parser didn't correctly match device types to original
addresses and handler IDs.
• Expanded the device types window capability to handle up to 255 types.
• Made ADB Parser System 7 happier. It now works in the background. It also
supports balloon help.
• Added Page Setup and Printing capability. You can now print the contents of
an active window.
• ADB Parser now remembers window sizes and locations. Upon launch, the
windows are opened and placed wherever they were when you last quit.
About the Apple Desktop Bus:
The Apple Desktop Bus (ADB) is a standard for input devices connecting to Apple computers that follow the Apple Desktop Bus protocol. In the Apple IIGS, the Apple Desktop Bus is run by a microcontroller that accepts input from the devices connected to the ADB, and makes appropriate calls to the Apple IIGS tools.
Because the Apple Desktop Bus is run by an intelligent microcontroller, a number of different types of input devices may be connected to the ADB simultaneously: the computer's keyboard and a mouse and perhaps a tablet, light pen, second keyboard, or joystick.
Each device has a unique bus address, so that the ADB microcontroller may direct its commands to a particular piece of equipment. The ADB is limited to a maximum of 16 unique devices. On the Apple IIGS, the control function is performed by the M50740 Keyboard Microcontroller. It uses a superset of the 6502 instruction set, and contains 96 bytes of RAM and 3K bytes of ROM. On the Macintosh SE and Macintosh II, the control function is performed by a microcontroller referred to as the "transceiver". The transceiver is located on the logic board of the Macintosh system.
When the microcontroller requests input from a device, it sends a signal to the input device to "talk". If no return input information action (key pressed, mouse movement, button clicked, etc.) has occurred, the microcontroller keeps waiting for the device to respond until a time-out occurs.
The host may also instruct a device to "listen" to data being sent on the bus from the host. All devices on the Apple Desktop Bus must include the intelligence to respond to both talk and listen commands.
The Apple Desktop Bus uses a 4-pin mini-DIN jack and a 4-wire cable, with serial interface signals. When appropriate, the input device will have two ADB jacks, so that devices may be daisy-chained from the host. The Apple Desktop Bus Mouse does not have a second connector, so it must be at the end of a chain.
- throughput: approximately 154 bytes per second
- cable length: maximum 5 meters
- cable capacitance: maximum 100 picofarads per meter
ADB devices may use the +5 volt power supplied by the bus, but must not draw more than 500 mA total for all devices. The Apple Standard Keyboard draws a maximum of 100 mA, and the Apple Extended Keyboard draws a maximum of 85 mA. All devices are connected in parallel, using the signal, power, and ground wires.
ADB devices are typically daisy-chained together. Some devices may contain enough internal resistance to limit the number of devices you can connect. For instance, a maximum of 4 Apple Keyboards or Apple Extended Keyboards plus 1 mouse may be daisy-chained together before increases in DC resistance result in drops below TTY levels. It is possible to connect 5 Apple ADB keyboards and a mouse together before resistance increases to where input via some devices will be "lost". Look out for other ADB devices that may have similar traits. Use of "low-power" ADB devices may allow more devices to function properly on the bus.
If input isn't reaching the CPU, break the chain into two chains (supported by 2 ADB ports on the Macintosh SE and Macintosh II). Alternatively, "Y" connectors could help create additional chains and reduce the number of devices on any one of those chains. If you manufacture cables to use with the ADB you must connect all four conductors in order to assure that all CPUs are fully functional. The following pin out chart may help in creating cabling.
The About window
This window can be opened by select About ADB Parser from the Apple () menu. The About Window displays revision level information. It also displays system configuration information. ADB Parser was written in Pascal and generated using MPW 3.2.
The ADB Parser window
This is the ADB Parser main window. Most program functions are conducted from within this window. The ADB Parser window is divided into three sections (left, center, and right). The left side of the screen is used for assembling and sending ADB commands. The center section displays a device list which consists of the current address, current type, current handler and original address of all devices known to the CPU. The right section of this display is used for setting new service routine and data area addresses.
The ADB Parser window is presented automatically when the program is booted. If the user closes the window, it can be reopened by selecting from the windows menu.
The Device Types window
This is the Device Types window. This window displays 16 device names. The mouse and keyboard default to original addresses of 2 and 3 and handler IDs of 1. In the future, devices may be designed which default to other addresses and handlers. The Device Types window allows the user to assign device names (for ease of reading) to these addresses and handlers. Although only 16 are displayed, the list may contain 255. Clicking in the scroll bar allows you to scan the list. To edit a device name, double-click on an item in the list. The following edit window will be presented.
Device names may be 25 characters in length (in the ADB Parser window, long device names are truncated to fit within the list). When the user has entered or changed the name of a device, clicking Okay will modify the lists in both the Device Types and ADB Parser windows. If Cancel is clicked no changes will be made. If any changes are made to the names, addresses or handlers in the Device Types window, the changes will be saved when the program is exited (or by selecting Save from the File menu). Original addresses must be in the range $0 to $F. Handler IDs must be a value no greater than 255.
The Memory Dump window
This is the Memory Dump window. This window displays a Hex dump of memory from a user definable starting address. When the program is booted for the first time, the starting address is assigned to the Global address which is the start of the ADB device table in RAM. Once the starting address value has been changed (you MUST enter 8 characters), it will dump from the new address. All addresses must be in Hex and four bytes in length. If the Update checkbox is selected (turned on) the screen will refresh automatically. This is useful in spotting data which is constantly changing. The scroll bar arrows may be clicked on so as to scan through memory. Clicking the scroll bars also changes the starting address for the dump.
The ADB Record window
This is the ADB Record window. A record of data pertinent to ADB is stored in RAM at a location beyond the device table. Many parameters needed for ADB operation are retained there. The ADB Record window displays these parameters in layman's terms. You can use the dump window to scroll beyond the ADB device record and view the ADB data record in hex format.
Menus:
The File menu provides access to file and printing functions. The Close item closes the currently active window. The Save item writes a resource which contains the list of device names, addresses, and handlers which can be seen in the Device Types window. It also saves the current Page Setup and window location and sizing information. Revert to Saved restores the information which is saved by the Save command. ADB Parser automatically saves when it quits. If you have altered device data or moved windows around but do not want these changes saved, select Revert to Saved before quitting ADB Parser. Page Setup brings up the standard print dialog which allows you to set various printing options. Print Window prints a copy of the currently active window using the Page Setup.
The Edit menu may be used to manipulate text within edit fields. When pasting into edit fields, ADB Parser analyzes the type of text and its length. Some of ADB Parser's edit fields only allow one character to be entered. If (in this case) the user attempts to paste data from the clipboard which is greater that one character, ADB Parser will generate a system beep and will not complete the paste.
The Options menu allows the user to choose whether information displayed in the Data bus monitor and Data received fields will be displayed in hexidecimal or binary form.
You may also choose to turn off the keyboard auto-repeat function. This is sometimes necessary when the keyboard resources or KMAPs get trashed on ADBReInit. It has been noted that on Mac SEs with some system files, an ADB ReInit causes the CPU to begin generating random keycodes which are uninteligible. Disabling auto-repeat stops this from happening.
The Windows menu is used to open ADB Parser windows. If a window is already open and it's title is selected from the menu, ADB Parser will bring that window to the front. Stack Windows aligns all open windows with the Menu Bar and offsets them so that their titles are visible. When you quit ADB Parser, all open window locations and sizes are saved. Upon relaunching ADB Parser, these windows are automatically opened and placed where they were. It is possible, by changing monitor configuations, for ADB Parser to place a window off the screen. Selecting Stack Windows will always retreive missing windows.
Using ADB Parser - Entering Commands:
Five radio buttons can be found in the left side of the ADB Parser main window. These buttons are used to define the type of command which will be sent. In the illustration below, the Talk command is highlighted.
This means ADB Parser is set to send a talk command. Clicking on any of the other four buttons will change the button highlighting and set ADB Parser to the new type of command. When a command is made active, certain edit fields will also become active. For example, a talk command requires no data, so the user is not able to click in the Data to send: edit field. Edit fields which are inactive have gray boxes drawn around them and edit fields which are active have black boxes.
This is an inactive field:
This is an active field:
When a command radio button is clicked, ADB Parser assembles and displays the command in the edit field titled The command:. This command is comprised of the data found in the fields The address: and The register:. If the user changes the address or register values, the command will also change. When entering address or register values, one hex character must be used. If an incorrect or invalid value is entered, ADB Parser will beep once and the data will not change. This is the only warning the user will receive. All values which are typed into the main window edit fields must be in hex. ADB Parser checks each entry and screens out input which is not valid.
Commands:
A Talk command is a request for a device to send data.
A Listen command is a request for a device to receive data or perform a service.
A Flush command generally causes a device to empty registers - this is device definable.
A Reset command sends a reset signal on the ADB to all devices. It resets all pending service requests and enables the service request mode of all devices on the bus. This puts devices in a mode in which they will accept commands.
Bus data monitor:
The Bus data monitor: is an inactive field which is used to display raw data as it passes through the ADB Data buffer. This field is never made active. The user may determine whether the display is in hexidecimal or binary format.
The Bus data monitor is capable of displaying eight bytes of information. Generally, mouse and keyboard activity uses only two bytes.
The address:
An edit field is available for setting the address value. The ADB has 16 valid addresses. The user may enter an address value from $0 to $F in hex. The value must be one character in length.
When the value of The address: is changed and the new value is valid, ADB Parser will assemble the new command and display it in the The command: field.
The register:
An edit field is available for setting the register value. Each device connected to the ADB contains four registers. Each register may store from two to eight bytes of data. Registers 0 and 3 have dedicated functions; registers 1 and 2 are used for device specific purposes and need not be present in a device.
If you type a value less that zero or greater that 3 ADB Parser will generate a system beep and ignore the input.
Register 0 is used for device input data. If a device has data to send, it places the data in register 0 and initiates an interrupt. The system collects this data by issuing a Talk R0 to the device which asserted the interrupt.
Register 1 may be used for device data and is user definable.
Register 2 is a data register for Talk commands returning information about the device. When Listen commands are used, the register may be used to send data or status unique to a device.
Register 3 is reserved for device identification data and operating flags.
Format of Device Register 3
The Command:
An edit field is available for displaying the current command. Normally, this edit field is inactive. The value shown in this edit field is the command which will be sent when the Send Command button is clicked.
When the Custom button has been selected the The command: edit field and four edit fields on the right side of the Parser window are enabled.
Custom commands work in one of two ways.
1) Clicking the Send Command button causes ADB Parser to call the ROM Trap ADBOp using the data from the The command: and Data to send: fields. ADB Parser ignores the data in the address and register fields and uses only the command which is entered in the The command: field. The command must be one whole byte (two characters). This function is provided for developers who may create new commands.
2) Clicking the Set ADB Info button causes the ADB Parser to alter the ADB Device Table. This is not done using normal ROM calls. The ADB Manager has no provisions for altering data in the ADB Device table. ADB Parser modifies the ADB Record using the information from the fields in the right of the window. When Set ADB Info is clicked, ADB Parser sets the Current Address, Original Address, Current handler, service routine address, and data buffer addresses for the device. If the device index already exists, ADB Parser replaces it's information with the new data. If the device index does not exist, ADB Parser creates a new one. This makes it possible to fill the ADB Record with simulated devices.
Data to send:
An edit field is available for entering the data to send to a device. This edit field is only active when either the Listen or Custom radio button has been selected. The user must enter data in whole bytes (two character increments). ADB Parser is capable of handling up to 8 bytes of data. The number of whole bytes is displayed above the edit field. As the user inputs new data, this value will be updated to reflect the change.
If the data which is entered is not comprised of whole bytes, ADB Parser will present an Alert dialog when the button is clicked. An error message will also be displayed in the Data received: field. Although ADB Parser does not use data from this field when executing Talk, Flush, or Reset commands, the data in this field must still be comprised of whole bytes.
Data received:
An edit field is provided which displays any data which might be received. This is only valid for a Talk command. On any other command, the data received will normally display the command or data which was sent.
The "Data received:" edit field is never made active. The user may determine whether the display is in hexidecimal or binary format.
Send Command:
Once a command has been satisfactorily assembled, clicking the button will cause ADB Parser to pass the Command and relevant data to the ROM Trap ADBOp. This Trap returns an error code which is displayed directly beneath the button. Under normal circumstances, the Trap result should be zero.
The Device List:
The center section of the ADB Parser window displays a device list. The device list contains records for all devices recognized by the ADB. When ADB Parser is first booted, this device list is assembled through use of the ROM Traps CountADBs and GetIndADB.
The device list may be updated by clicking the ADB ReInit button. This causes ADB Parser to call the ROM Trap ADBReinit. It is also possible to add or remove devices from the list using the Custom command and setting ADB Info.
When the ADB ReInit button is clicked, APB Parser rebuilds the device list. This is the normal way a Macintosh will recognize a device which was introduced to the ADB after system boot-up. If the user is running ADB Parser and connects new devices to the CPU, this function must be used for the CPU to recognize these devices and move them into unique addresses. Devices may be recognized and moved manually through the use of the Custom-Set ADB Info function.
The device list displays an apple symbol () to the left of one of the devices in the list. This symbol is used to indicate which device was the last device to communicate on the bus. At times this will represent the device which the user sent the last command to, other times it will be an indication of the device which is currently being auto-polled.
Clicking the mouse on an item in the device list will cause the highlighting to move to that item (in the above illustration the mouse in address 3 is highlighted). Clicking on an item will cause its data to be transferred to the edit fields in the right section of the main window.
Setting ADB Info:
On the right section of the main window two edit fields are provided for entering new service routine and data area addresses. Clicking on an item in the device list will transfer the device data into these fields. The Current address: field will reflect the address of that item. When the Set ADB Info button is clicked, this data will be placed in the ADB device table VIA the ROM Trap SetADBInfo at the address shown in Current address:.
Any result from the Trap SetADBInfo will be displayed directly below the Set ADB Info button. The Trap result will normally be zero.
Caution! There are no Trap routines which allow APB Parser to change or set the original address, current address, or current handler. ADB Parser does allow this. Warning, this can be dangerous! Refer to the section of this manual which discusses Custom commands.
Error Alerts
If you have not entered the proper type of data, ADB Parser may complain. If this happens you may see a dialog (alert) which looks like this:
This will only happen if you are sending a command or setting ADB info. Generally, this error will occur if you have failed to type a value in an edit field. It will also occur if you are sending a command and have defined an odd number of data bytes.
If you are editing a Device Type and attempt to set an original address value greater than $F, ADB Parser will register the following complaint:
ADB Parser does some other error checking, in most cases, if you make a minor mistake it will generate a system beep. If you make a major blunder, you’ll probably lock-up or get the bomb.
Practical Examples - Apple Extended Keyboard
Talk Register 0:
This command pulls in new input data if any exists. Unless you are really fast you will probably never see any. Still if you want to do it here's how:
Configure the ADB Parser as shown in the illustration above. Click the button. This sends a Talk R0 command to address 2. Any information the device reports will be seen in the Data received: field.
Talk Register 2:
This command returns the status of special keys and LEDs. To understand the data you receive you probably should consult the keyboard specification. At any rate, you can execute this command by setting up ADB Parser as follows:
Click the Send Command button. This sends a Talk R2 command to address 2. If the caps lock key is up you should receive $FFFF. If the caps lock key is down you will receive $DFFD. There are lots of other variations.
Talk Register 3:
This command forces a data collision if more that one device exists at the address. Devices will move to a different address if they are enabled and have been issued a Listen R3 with valid data prior to the Talk R3. To send this command, follow the steps described for a Talk R2 but change The register: field to 2. A Talk R3 command returns data in the Data received: field. This register returns the following data:
The address field of register 3 returns a random number from $0 to $F on a Talk R3. This facilitates device identification when the CPU attempts to differentiate devices during collisions. Each Talk R3 should generate a different random value.
Listen Register 2:
This command accompanied by any data sets the state of the LEDs. To send a Listen R2 set up the ADB Parser as follows:
Sending data of $0000 will cause all three LEDs to light. Sending $000F will turn them all off. Sending $0003 will turn on only the scroll lock LED. There are a whole bunch of possibilities. Note that only bits 1-4 of the data are accepted. You must send 2 whole bytes, but bits 5-15 are regarded as filler.
Listen Register 3:
This command is used to modify the device handler ID. The following list of handler IDs describes the use and function:
$00FF initiates the self test - if fails will return $00
$nnFE enables device to move to a new address (nn)
$nnFD moves device to new address (nn) if activator is pressed ( key)
$0003 enables alternate keys (sets handler to 3)
Practical Examples - Apple Mouse
Talk Register 0
Same as Extended keyboard.
Talk Register 3
Same as Extended keyboard.
Listen Register 3
This command is used to modify the device handler ID. The following list of handler IDs describes the use and function:
$00FF initiates the self test - if fails will return $00
$nnFE enables device to move to a new address (nn)
$nnFD moves device to new address (nn) if activator is pressed ( key)
$0002 enables high resolution (sets handler to 2).
